Added [System.Flags] to enums that are flags. - #354

Thanks for this, and sorry it sat for so long. Two things I want to say before the changes: you filed the issue, implemented it, and then came back and rebased onto 9.0.1.1 the same day it shipped. And the generated files in the branch reproduce byte-for-byte from your generator — I checked with git diff --exit-code -- '*.g.cs' after a clean regeneration. That is rarer than it should be, and it made this reviewable in minutes.

I have pushed a commit onto your branch rather than sending you round another lap. Look it over and push back on anything you disagree with.

What I changed and why

The detection keyed on the header spelling a member as 1 << n. That makes the outcome depend on how FFmpeg formatted its source rather than on what the enum means, and it misses real bitmasks:

SWS_BACKEND_C = (1 << 1),                        // parenthesised - the regex is anchored to $
AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX = 0x01,  // hex
AV_SIDE_DATA_PARAM_CHANGE_SAMPLE_RATE = 0x0004,  // hex, and the header's own docs use it as a mask

All three are documented bitmasks. The sharper worry is that this can flip with no change on our side: if upstream ever reformats 1 << 3 to (1 << 3), the attribute silently disappears.

So IsFlags now lives on EnumerationDefinition and is computed in the processor from the numeric values: at least two distinct single-bit members, at most a couple of named aggregates like SWS_BACKEND_ALL, every aggregate covered by bits the enum introduces, *_MAX_ENUM = INT_MAX sentinels ignored, and a consecutive run rejected so 0, 1, 2 stays a sequence. EnumsGenerator reads that instead of looking for << in the text it is about to print.

Net effect, 5 enums marked before, 8 now:

AvFrameCrop is an honest loss and worth flagging: it has a single member, and by values alone AV_FRAME_CROP_UNALIGNED is indistinguishable from AV_HWFRAME_TRANSFER_DIRECTION_FROM/TO, which is a direction, not a mask. If we want the single-bit ones (AvFrameCrop, AVClassStateFlags, AvOptFlagImplicit) an explicit list is probably more honest than another heuristic.

Keeping the shift spelling

I kept it — reading like the header is genuinely useful when you are porting C code across — but it is now independent of detection and verified, because C# masks shift counts. X = 1 << 40 in a 32-bit enum compiles as 1 << 8, so the literal is only kept when 1UL << n actually equals the value clang computed; otherwise it falls back to the number. It also now matches the parenthesised form, which is why more members render as shifts than before.

The suffix comes from the type name the enum is generated with, rather than a second PrimitiveType table. That table had no cases for LongLong/ULongLong — the two that really are C# long/ulong — and disagreed with TypeHelper about Long/ULong, which map to CLong/CULong since #359.

Smaller things

• EnumerationItem keeps a numeric Value and gains Literal. ASTProcessor publishes Value into WellKnownEnumItems, where it is spliced into macro bodies as text — an unparenthesised 1 << 3 there would have changed the precedence of any macro referencing the member. It does not fire on today's headers, but the coupling was there.
• ConvertValue now formats with InvariantCulture. Enums.g.cs has negative members, and on sv-SE, fi-FI, nb-NO and lt-LT (-1).ToString() returns U+2212 MINUS SIGN, which does not compile. That one predates your PR, it just happened to be on the line you were editing.
• Named regex group instead of Groups[1], matching what the generator does elsewhere.
• using System; only when something is actually marked.

One question for you

swscale.h says of SWS_FAST_BILINEAR..SWS_SPLINE: "Scaler selection options. Only one may be active at a time." So SwsFlags is really a selector in its low bits and a flag set in its high ones, and [Flags] blesses SWS_BILINEAR | SWS_BICUBIC, which the header forbids. #353 asked for the attribute and I have left it on, but you have looked at this enum more recently than I have — if you think it should be split or left alone, say so.

Worth knowing for scale, by the way: FFmpeg keeps almost all of its flags in macros, not enums — 149 #define ..._FLAG... and 195 #define X (1 << n) against 8 flag-shaped enums. Those become plain constants in ffmpeg.macros.g.cs, so no attribute can reach them.